So far I've noticed that the Optimization and Serial interface options are missing for maple mini.

Simply copying the board text and replace genF103. with Maple. works compiles.

There seems to be a problem with maple mini sketches uploaded via STLink. They do not start by themselves (not even after reset), but start working after being hooked up to a debugger.

Maple mini I2C wirescanner example works (once kickstarted by debugger)

Maple mini tests:

• STLink upload works (if old platform.local.txt lines are removed 😄)
• Serial ok
• I2C ok
• PWM ok

Thanks @lacklustrlabs
You're right, I've forgot to add those menu for Maple.
It's now corrected.
I'm wondering if I should align the pins mapping of the BluePill on the Maple one.
Maple silkscreen is the pin numbering while the BP one is the pins name but maybe I should align the pin numbering btw variant. I did not do that for BP to avoid duplicated pin for ADC due to restriction of #214

I'm wondering if I should align the pins mapping of the BluePill on the Maple one.

Imho - It would be best if maple mini could use Dx notation while BluePill uses Pxy (If possible)

The problem with MM (both BP & MM) stlink autostart persists. Blinky does not blink unless first connected to a debugger, after that it works standalone. (have not yet tested serial upload)

Imho - It would be best if maple mini could use Dx notation while BluePill uses Pxy (If possible)

Core is able to deal with both notation.
ex:
BP: D0 == PB9
MM: D0 == PB11

For STLink issue I do not have this issue with BP.
What is your Boot0/1 config?

Core is able to deal with both notation.

Yes, i know. It was for human-readability purposes. By tradition pin numbers (Dx) means nothing to BP users. Their silkscreen is using Pxy notation.

I've never touched the Boot0/1 config, i know my current setting works for the maple core and my temporary rebased MM&BP branch for this core. But i suspect that the problem may be the bootloader (or possibly lack of it). I have not used it much since I switched over to STLink.
I'll investigate some more...

Btw, i would not object to a MM&BP bootloader menu with the options None(stlink), Original (17kb ram) and new (20kb ram)

Yes, i know. It was for human-readability purposes. By tradition pin numbers (Dx) means nothing to BP users. Their silkscreen is using Pxy notation.

Ok. So, nothing to handle as all notations are manage.

Btw, i would not object to a MM&BP bootloader menu with the options None(stlink), Original (17kb ram) and new (20kb ram)

I do not understand well your request. Could you explain me what you would behind those menu?

Just like the maple stm32 core:
The "no bootloader" option would place the bin at 0x8000000 (as stlink upload does now)
'Original' at 0x8005000 and
'Bootloader 2.0' at 0x8002000

Ok. But currently, I will not have time to handle this. This could be part of future PR for those variants.
Including USB (CDC, DFU,..)
Goal of this PR is to provide basic support.

I'm not sure how many people would use an option which was Maple Mini with No Bootloader

The bootloader comes preinstalled with the Maple Mini, and hardly anyone reloads the board via STLink etc as it doesnt have a separate pin header for STLink like the Blue Pill does

Yes, but it is better havr an official basic support and after start to work on usb.

Maple have the serial like Bluepill, it is enough gor starting imho

I understand @rogerclarkmelbourne
This will come... I will get MM in march then I could go further.
Anyway if some user could help, they are welcome ;)

bluepill is always using ldscript.ld, regardless of flash size.

boards.txt:

GenF103.menu.flash.C8=64k (default)
GenF103.menu.flash.C8.upload.maximum_size=65536
-GenF103.menu.flash.C8.build.ldscript1=ldscript.ld
+GenF103.menu.flash.C8.build.ldscript=ldscript.ld
GenF103.menu.flash.CB=128k
GenF103.menu.flash.CB.upload.maximum_size=131072
-GenF103.menu.flash.CB.build.ldscript1=ldscript_cb.ld
+GenF103.menu.flash.CB.build.ldscript=ldscript_cb.ld

Oops... sorry wrong commit... I've made a test and commit it by error during the rebase. Nice shot ;)

great to have this merged.

anyone knows where to subscribe to track the addition of USB bootloader support?
found it
(it appeared in between the time I've read this bug and had the chance to write a comment)